I've approved, but before I merge can you walk me through an example of what used to happen and what will happen now with the fix instead which would prevent this from being deleted by the DeleteOrphanWorkflow? I'm having trouble understanding the moving pieces.

I've approved, but before I merge can you walk me through an example of what used to happen and what will happen now with the fix instead which would prevent this from being deleted by the DeleteOrphanWorkflow? I'm having trouble understanding the moving pieces.
@patelspratik

We identified two root causes for the bug where Nebius instances were being deleted from dev environments:

1. An incorrect tag for the stage (which we’ve addressed in this PR).
2. The CloudCredRefID for Nebius instances wasn’t being persisted.

When we looked into how Nebius handles tags, we found that during instance creation, the CloudCredRefID label isn’t stored as a tag (reference). Additionally, when listing instances, Nebius always sets CloudCredRefID to the current client’s refID, not the creator’s (reference):

inst := &v1.Instance{
    RefID:          refID,
    CloudCredRefID: c.refID,  // ← Always uses the CURRENT client's refID, not the creator's!
}

In contrast, other providers like Shadeform store the cloudCredRefID as a tag when creating an instance and then read it from the tags when listing instances (for-ref, for-ref):

cloudCredRefID, found := tags[cloudCredRefIDTagName]
if !found {
    return nil, errors.WrapAndTrace(errors.New("could not find cloudCredRefID tag"))
}

Nebius had CloudCredRefID set to current CloudCredRefID, which allows these instances to bypass the CloudCredRefID check. We have resolved this bug in the current PR by ensuring that the correct CloudCredRefID is now properly stored and utilized.